The controller area network (CAN) is a standard for message-based, distributed communications in industrial, automotive and instrumentation applications. The International Organization for Standardization released the original CAN standard in 1993 (ISO 11898) which has been further developed and refined since then. Some of the CAN features include multiple masters on a bus, inherent priority levels for messages, bus arbitration by message priority, error detection and recovery at different levels as well as synchronization of timing across nodes in spite of separate clock sources. The CAN protocol supports differential data transmission and thus bidirectional communications across a twisted pair cable as well as an increased immunity to noise.
Implementations of controller area networks are typically based on three components: transceivers, controllers and microcontrollers. Physical layer transceivers are required to ‘translate’ the CAN messages to/from differential signals exchanged across a physical medium such as a twisted pair cable. CAN controllers are required to implement the data link layer as defined by the ISO/OSI model. Finally, microcontroller units (MCUs) handle CAN messages at the higher levels of the ISO/OSI model. In its simplest form, the data path thus comprises an MCU coupled to a CAN controller which, in turn, is coupled to a CAN transceiver wherein the CAN transceiver is connected to a CAN bus. Taken together, the MCU, CAN controller and CAN transceiver define a CAN node.
CAN systems frequently have to communicate over multiple CAN networks/buses. A straightforward solution would be to use N data paths in case the system has to communicate over N CAN buses. However, even if a single MCU was used to serve the N CAN transceivers and N CAN controllers, this approach would increase power-consumption to such an extent that it may be unacceptable in many applications, especially automotive applications where low-power consumption is of fundamental importance. Despite these strict low-power requirements, however, such in-car systems must be able to filter incoming messages with respect to their relevance and quickly react to relevant messages (typically within 25 ms). An example for such a message is an “Emergency Audio” request which requires immediate playback of a pre-defined audio signal, e.g., emergency alert, unbuckled seat belt and the like.